home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c,comp.std.c
- Path: nntp.coast.net!torn!sq!msb
- From: msb@sq.com (Mark Brader)
- Subject: Re: Integral conversion e.t.c. (was: Re: Hungarian notation)
- Message-ID: <1996Feb7.185509.10227@sq.com>
- Organization: SoftQuad Inc., Toronto, Canada
- References: <30C40F77.53B5@swsbbs.com> <SPENCER.96Jan22113215@zorgon.ERA.COM> <KANZE.96Feb5133404@slsvewt.lts.sel.alcatel.de> <823699045snz@genesis.demon.co.uk>
- Date: Wed, 7 Feb 1996 18:55:09 GMT
-
- > I'm not quite clear on the intention of the standard here. As a
- > categorisation of types of error it is useful to distinguish between
- > errors that require a diagnostic and plain undefined behaviour. However
- > when a diagnostic is required clearly the result is undefined behaviour.
- >
- > 3.16 Undefined behaviour
- > "Behaviour, upon use of a nonportable or erroneous program construct"
- > "... or by the omission of any explicit definition of behaviour"
- > These would seem to cover syntax errors and constraint violations.
-
- Are there really official copies of the standard that spell it "behaviour"?
- Just curious.
-
- Yes, it is correct that when a diagnostic is required, the behavior is
- otherwise undefined. To avoid any confusion: the undefined behavior
- cannot extend to omitting the diagnostic. This was made explicit in
- Technical Corrigendum 1, which changed the first sentence of 5.1.1.3 to:
-
- # A conforming implementation shall produce at least one
- # diagnostic message (identified in an implementation-defined
- # manner) for every translation unit that contains a violation
- # of any syntax rule or constraint, even if the behavior is also
- # explicitly specified as undefined or implementation-defined.
- --
- Mark Brader, msb@sq.com | "However, 0.02283% failure might be better than 50%
- SoftQuad Inc., Toronto | failure, depending on your needs." -- Norman Diamond
-
- My text in this article is in the public domain.
-